It is well known in computer science that programs tend to spend 90% of their time executing 10% of the code. The corollary of this is that if a programmer can speed up this 10% of the code by say 100%, then the resulting program will run almost 100% faster, without the necessity of touching any of the rest of the code.
Determining exactly where a program spends its time when executing is thus important. Many programmers believe that they can determine this by looking at the program and guessing. They are usually wrong. Experience has shown that the only real way to determine the part of code that a program tends to execute is through performance measurements.
Often these days crude performance-monitoring tools are provided with modem operating systems. For example, Microsoft Windows NT 4.0 provides both a Performance Monitor tool and a Task Monitor tool. The later tool provides real-time statistics on how much processor resources are currently being utilized by the active programs and tasks running in the system. This allows an analyst to determine which programs and which parts of the operating system are being utilized. This sort of measurement is fairly gross, and is typically gathered through the system dispatcher. Neither tool provides the fine-grained performance statistics necessary in determining where to optimize a program.
In order to gather finer performance statistics, measurement, or instrumentation code is often compiled or link/edited into programs whose performance is to be measured. At its simplest, the instrumentation code counts how often a function or procedure is invoked. This can be done by incrementing a counter whenever the function or procedure is entered. This type of instrumentation usually results in more precise and finer grained measurements than are typically available today through dispatcher based measurements.
One problem that arises in some situations from this sort of counterbased measurement is that procedure or function invocation counts do not translate directly into the time being spent in a particular part of the code.
It would therefore be useful to have available to programmers and analysts the ability to perform fine grained-instrumentation in which it can be determined accurately where a program spends most of its time during execution.